Conventional modern communication and some conventional modern navigation systems employ at least some form of information security and, hence often require cryptography. A conventional transceiver system for a radio may comprise numerous processing subsystems for each channel. For example, a transceiver unit may contain a digital signal processing subsystem, a black processing subsystem, a cryptographic subsystem, a red processing subsystem, etc. for each channel. In military communication systems and selected commercial communication systems the cryptography system and method employed are often computationally complex. Furthermore, recent mandates from the National Security Agency (NSA) and the Department of Defense (DOD) require cryptography implementations to be programmable so that algorithms can be switched and updated. International military customers may wish to create and implement their own unique or “country-specific” cryptography algorithms.
To date, computationally complex and programmable cryptography has been implemented using “programmable crypto engines” that are sometimes hardware and sometimes software programmable. In either case, the implementation of a given algorithm requires detailed technical knowledge of the engine architecture and instruction set. For crypto engines that provide multi-level security (MLS) or multiple single levels of security (MSLS), the implementation expertise and domain knowledge requirements are even greater. This required expertise precludes many international customers from implementing their own unique or “country-specific” algorithms. The proprietary nature of some of these cryptographic engines also makes it difficult for one company or customer to implement new algorithms without the consent of likely unwilling corporate competitors.
Even if one were to overcome the domain knowledge issue, once the algorithms are implemented, they are not portable to other cryptographic engines. The unportability of the crypto engines is due to the architectures of the engines on the market today (e.g. Harris Sierra I and II, GD AIM Engine, and Raytheon Cornfield) and those under development (such as NRL PEIP II and Rockwell Collins Janus), have almost completely different architectures. The constituent elements, e.g., processors, FPGAs, memory devices, etc., are also almost always different.
What is needed, therefore, is a system and a method that overcomes one or more of the deficiencies described above. What is needed is an approach that “abstracts away” the specifics of the hardware architecture must be used, so that the primary algorithm software can be easily rehosted on any cryptographic engine that employs such abstraction. No such approach has been developed and applied to cryptographic engines.
It would be desirable to provide a system and/or method that provides one or more of these or other advantageous features. Other features and advantages will be made apparent from the present specification. The teachings disclosed extend to those embodiments which fall within the scope of the appended claims, regardless of whether they accomplish one or more of the aforementioned needs.